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ABSTRACT 

We  present  in  this  study  an  integrated  systems  design  for  a  VLSI  multipro- 
cessor capable  of  generating  contour  surface  displays  in  real-time  (one-thirtieth  of 
a  second).  We  begin  by  examining  an  application  that  requires  real-time  contour 
surface  display  generation  J10.  We  sketch  some  outlines  for  an  architecture 
based  upon  a  decomposable  algorithm  recently  published  [  12'.  We  then  propose 
an  architecture  for  a  single  board  VLSI  contour  surface  display  generator  that  is 
pluggable  into  the  Multibus  of  the  Silicon  Graphics,  Inc.  IRIS  workstation. 

Categories  and  Subject  Descriptors:  1.3.1  [Hardware  Architecture]:  architec- 
tures, parallel  processing.  VLSI  implementations:  1.3.2  [Graphics  Systems]: 
multiprocessing  systems:  I  3.5  [Computational  Geometry  and  Object 
Modeling]:  data  structures,  discrete  planar  contours,  modeling  molecules,  surface 
approximation,  surface  generation,  surface  representation,  surfaces,  3D  graphics: 
1.3.6  [Methodology  and  Techniques]:  contouring,  interactive  systems,  parallel 
processing:  1.3.7  [Three-Dimensional  Graphics  and  Realism]:  line  drawings, 
line  generation  algorithms,  real-time  graphics,  surface  plotting,  surface  visualiza- 
tion, surfaces;  1. 3m  [Miscellaneous]:  VLSI; 

General  Terms:  Algorithms,  architecture; 

Additional  Key  Words  and  Phrases:  contouring,  contouring  tree,  contour  surface 
display  generation,  real-time  display  generation; 

1.    Introduction 

Contour  surface  display  generation  is  one  of  the  most  frequently  used  applications  graphics 
algorithms     1.  3.  8-16       A  contour  surface  display   is  a  visual  representation  of  a  surface  b>    the 
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collection  of  lines  formed  when  that  surface  is  intersected  by  a  set  of  parallel  planes  (Figure  1). 
The  lines  formed  on  each  of  those  planes  are  called  contours  A  contour  represents  the  set  of 
points  that  belong  to  both  the  surface  and  the  particular  intersecting  plane.  Contour  surface 
displays  are  used  in  X-ray  crystallography,  computer-aided  tomography,  and  other  applications 
for  which  grid  data  is  collected.  Contour  surface  display  generation  is  generally  depicted  as  a 
computationally  slow  operation  whose  output  is  sent  to  a  plotter  or  film  recorder.  One  publica- 
tion has  described  an  architecture,  and  produced  a  feasibility  determination  for  a  VLSI  based  con- 
tour surface  display  generator  ,10).  The  architecture  proposed  in  that  study,  while  appropriate  for 
its  level,  does  not  provide  enough  detail  for  actual  implementation.  Neither  does  that  study  con- 
sider some  of  the  issues  that  occur  when  one  actually  designs  a  working  system.  This  study 
attempts  to  remedy  those  deficiencies  by  providing  an  integrated  systems  architecture  for  a  real- 
time contour  surface  display  generator  that  is  both  precise  in  detail,  and  technologically  realistic. 

1.1.    Contour  Surface  Display  Generation  is  Slow 

Our  initial  premise  for  this  study  is  that  contour  surface  display  generation  on  a  single  pro- 
cessor system,  such  as  a  graphics  workstation  with  a  floating  point  accelerator,  is  too  slow  to  be  of 
any  use  for  interactive  applications  requiring  such  a  display.  This  premise  is  based  upon  10  ,  and 
is  reinforced  by  statements  found  in  the  literature.  A  number  of  papers  have  been  written  docu- 
menting "breakthroughs"  that  increase  the  speed  of  contour  surface  display  generation  One 
author  has  reported  that  his  contour  surface  display  generation  subroutine  used  one  second  of  cen- 
tral processor  time  on  NCAR's  Control  Data  7600  9  .  Although  a  contour  surface  display  genera- 
tion program  of  this  speed  is  useful  for  static  situations,  it  is  unacceptable  for  applications  that 
generate  a  succession  of  contour  surface  displays  in  response  to  contour  level  changes  read  from  a 
control  dial.  Such  a  program  requires  that  a  new  contour  surface  display  be  generated,  distri- 
buted, and  displayed  in  real-time,  typically  one-thirtieth  of  a  second  for  current  display  technol- 
ogy   6 

One  application  in  which  real-time  contour  surface  display  generation  is  important  is  the 
determination    of   molecular    structures     from    the    electron    density     data    generated    by    X-ray 
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Figure  1 

Contour  Surface  Display  Generated  from  a  Hydrogen  Atom 

Wavefunction  Squared  (3dz2  orbital) 


crystallography  |lj.  Such  an  operation  is  executed  interactively  by  using  a  computer  graphics 
program  that  displays  a  Dreiding  (stick)  model  of  the  molecule  inside  a  contour  surface  display  of 
the  corresponding  region  of  the  molecule's  electron  density  grid.  In  addition  to  the  graphics  func- 
tion, the  computer  program  monitors  a  series  of  signals  generated  by  the  user,  while  the  user  is 
turning  the  various  knobs  on  a  control  console  |17].  The  values  read  from  these  knobs  are  inter- 
preted by  the  program  as  modifications  to  either  the  molecule  or  the  surface  display.  Modifica- 
tions to  the  molecule  take  the  form  of  bond  rotations  or  bond  lengthenings.  Modifications  to  the 
contour  surface  display  take  the  form  of  an  increase  or  decrease  of  the  contour  level.  The  goal  of 
this  process  is  to  produce  the  stick  model  of  the  molecule  that  best  fits  inside  the  given  electron 
density  data  set.  The  user  can  determine  whether  or  not  the  model  fits  the  density  grid  by  modi- 
fying the  contour  level,  shrinking  the  contour  surface  to  the  molecule.  Similarly,  the  user  can 
expand  the  contour  surface  from  the  stick  model  for  better  visibility.  This  function  requires  that 
the  hardware  have  the  capability  to  rapidly  change  the  contour  display  as  its  contour  level 
changes. 

We  know  from  [13]  that  the  generation  of  a  contour  surface  display,  such  as  those  required 
by  the  above  application,  cannot  be  accomplished  in  real-time  using  a  conventional  uniprocessor. 
This  failure  is  due  to  the  fact  that  contour  surface  display  generation  algorithms  require  many 
more  instructions  executed  per  second  than  can  be  provided  by  currently  available  uniprocessors. 
In  the  past,  this  limitation  of  the  conventional  processor  has  relegated  such  applications  to  either 
the  non  real-time  environment  (waiting  a  few  minutes  for  each  display),  or  to  the  equally  unsatis- 
fying environment  of  motion  picture  film.  Because  of  this,  the  author  of  '10  looked  for  a  mul- 
tiprocessor solution  to  the  real-lime  contour  surface  display  generation  problem.  At  the  time  of 
that  study,  efficient  multiprocessor  solutions  meant  VLSI  solutions.  Consequently,  the  multipro- 
cessor architecture  proposed  in  that  study  was  qualified  by  the  need  for  implementation  in  VLSI. 
This  study  continues  with  that  qualification. 
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1.2.    Contouring  Definitions 

A  contour  surface  is  a  visual  display  that  represents  all  points  in  a  particular  region  of 
three-space  <x,y,z>  which  satisfy  the  relation  f(<x,y,z>)  =  k,  where  k  is  a  constant  known  as  the 
contour  level  (Figure  1).  The  function  f  represents  a  physical  quantity  which  is  defined  over  the 
three-dimensional  volume  of  interest.  The  visual  display  created  by  this  algorithm  is  the  collec- 
tion of  lines  that  belong  to  the  intersection  of  both  the  set  of  points  that  satisfy  the  relation 
f(<x,y,z>)=  k,  and  a  set  of  regularly  spaced  parallel  planes  that  pass  through  the  region  of  three- 
space  for  which  the  relation  is  defined. 

For  this  study,  the  function  f  is  approximated  by  a  discrete,  three-dimensional  grid  created 
by  sampling  that  function  over  the  volume  of  interest  The  three-dimensional  grid  contains  a 
value  at  each  of  its  defined  points  that  corresponds  to  the  physical  quantity  obtained  from  the 
function,  i.e.  the  value  associated  with  point  (x„,y0.z0)  is  v_,  where  f(xr)>yr)'zo)=vO' 

A  decomposable  algorithm  for  contour  surface  display  generation  is  described  in  [12].  That 
algorithm  is  constructed  from  a  two-dimensional  contouring  algorithm  that  is  used  to  contour  all 
the  possible  planar,  orthogonal,  two-dimensional  grids  of  a  larger  three-dimensional  grid.  The 
two-dimensional  contouring  algorithm  of  that  study  is  comprised  of  components,  called  algorithm 
components,  that  operate  on  individual  2x2  subgrids  of  a  larger  two-dimensional  grid.  (Note:  a 
2x2  subgrid  is  defined  to  be  that  portion  of  the  two-dimensional  grid  bounded  by  four  adjacent 
grid  points.)  In  the  algorithm,  the  computations  necessary  for  generating  the  contour  lines  for  a 
single  2x2  subgrid  are  independent  from  those  required  for  any  other  2x2  subgrid.  If  we  com- 
pute the  contours  corresponding  to  contour  level  k  for  all  2x2  subgrids  of  a  two-dimensional 
grid,  then  we  will  have  determined  the  complete  set  of  contours  for  that  grid.  If  we  compute  the 
contours  corresponding  to  contour  level  k  for  all  possible  2x2  subgrids  of  the  larger  three- 
dimensional  grid,  then  we  will  have  the  complete  contour  surface  display  for  that  grid.  The 
assemblage  of  the  contours  created  by  this  process,  i.e.  the  simultaneous  display  of  all  the  con- 
tours created  for  all  2  x  2  subgrids  of  the  larger  three-dimensional  grid,  produces  a  "chicken-wire- 
like" contour  surface  display  (Figure  1).    The  full  development  of  this  algorithm  can  be  found  in 


[11-13].  We  refer  to  the  results  of  those  studies,  and  consequently,  do  not  cover  the  algorithm 
here  in  great  detail.  We  only  note  that  for  the  largest  three-dimensional  grid  of  interest  for  the 
above  application,  a  30  x  30  x  30  grid,  this  means  the  potential  for  75,690  parallel  operations  (see 
Figure  2  and  jlj). 

2.  Architectural  Goals  for  the  Contour  Surface  Display  Generator 

The  first  goal  in  the  design  of  the  contour  surface  display  generator  is  to  build  a  system  that 
meets  the  performance  requirements,  i.e.  a  new  contour  surface  display  computed  from  a 
30  x  30  x  30  grid,  and  delivered  to  a  display  device  in  one-thirtieth  of  a  second.  This  is  an  ambi- 
tious goal  but  it  must  be  noted  that  one-thirtieth  of  a  second  is  the  maximum  amount  of  time 
allowable  for  the  operation  Any  longer  amount  of  time  does  not  provide  the  viewer  smooth  tran- 
sitions between  successive  contour  surface  displays  This  goal  says  nothing  about  the  load  time  of 
the  30  x  30  x  30  grid  to  the  special  piece  of  hardware  that  computes  the  contour  surface  display 
Consequently,  we  allow  solutions  that  pre-load  the  grid. 

The  second  goal  for  the  construction  of  the  contour  surface  display  generator  is  that  we  be 
able  to  plug  it  into  an  existing  graphics  system  with  minimal  hardware  and  software  changes.  For 
the  purposes  of  this  study,  the  target  graphics  system  is  chosen  to  be  the  Silicon  Graphics,  Inc. 
IRIS  workstation  (see  Figure  3  and  2  ).  The  Silicon  Graphics,  Inc.  IRIS  is  currently  the  highest 
performance  graphics  system  that  best  matches  the  selected  application's  goals. 

3.  Architecture  of  the  Contour  Surface  Display  Generator 

There  is  not  enough  space  in  this  paper  to  present  the  complete  architecture  of  the  contour 
surface  display  generator  The  reader  is  instead  referred  to  8  .  An  overview  architectural 
description  is  that  the  contour  surface  display  generator  is  comprised  of  four  subsystems:  (1)  the 
array  of  algorithm  component  processors.  (2)  the  controller  for  that  array  of  processors.  (3)  the 
algorithm  component  processor  itself,  and  (4)  the  interface  to  the  graphics  system.  Figure  4 
shows  how  the  four  subsystems  relate  to  the  target  graphics  system. 
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Figure  3 
Block  Diagram  of  the  Silicon  Graphics,  Inc.  IRIS 
(with  additional ,  non-SGI  Contour  Surface  Display  Generator) 
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Figure  4 
Contour  Surface  Display  Generator:  Buses  and  Data  Flow. 
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Figure  4  depicts  the  array  of  algorithm  component  processors  as  a  single  box,  with  three 
connections  to  the  outside  environment:  an  input  bus  for  contour  levels  and  subgrids,  an  output 
bus  for  coordinates  and  drawing  instructions,  and  a  bus  for  controlling  the  array  of  processors.  A 
dual  bus  configuration  is  chosen  to  maximize  the  amount  of  concurrency  in  the  system  due  to  the 
autonomous  nature  of  the  input  with  respect  to  the  output. 

The  input  bus  is  the  medium  responsible  for  delivering  subgrid  definitions  and  contour  levels 
to  the  array  of  algorithm  component  processors.  Because  this  is  the  only  data  required  to  be 
transmitted  on  the  bus,  the  bandwidth  of  the  input  bus  does  not  need  to  be  very  high.  The  rate 
at  which  subgrid  definitions  are  loaded  into  the  algorithm  component  processors  does  not  directly 
affect  the  real-time  capabilities  of  the  system.  The  real-time  capabilities  of  the  contour  surface 
display  generator  are  determined  by  the  rate  at  which  data  can  be  produced  in  each  algorithm 
component  processor.  This,  in  turn,  directly  affects  the  rate  of  output  to  the  display  processing 
unit.  The  output  bus  is  responsible  for  delivering  the  coordinates  and  drawing  instructions  to  the 
display  processing  unit. 

The  control  bus  for  the  contour  surface  display  generator  contains  all  the  control  lines  neces- 
sary to  manage  the  data  flow  on  the  input  side  of  the  system.  Two  additional  control  lines  are 
required  on  the  output  side  of  the  system  to  coordinate  the  two  wire  handshake  between  the  algo- 
rithm component  processors  and  the  display  processing  unit  (Geometry  Engines). 

Control  of  the  array  of  algorithm  component  processors  involves  the  integration  of  several 
different  components.  The  one  which  coordinates  the  operation  of  all  other  components  is  the 
systems  controller  (Figure  S).  The  systems  controller  converts  incoming  signals  from  the  Mul- 
tibus bus  master  of  the  Silicon  Graphics.  Inc.  IRIS  workstation  into  signals  which  make  sense  to 
the  algorithm  component  processors.  The  Multibus  bus  master  is  the  board  in  the  Multibus 
Backplane  which  places  the  commands  on  the  Multibus.  The  systems  controller  is  a  slave  in  that 
it  reacts  to  commands  placed  on  the  Multibus. 

The  component  that  is  responsible  for  the  production  of  the  coordinates  and  drawing 
instructions    for    the    contour   surface    display    generator    is    the    algorithm    component    processor 
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(Figure  5).  Each  of  these  processors  is  identical  and  functions  independently  in  the  production  of 
the  outputs.  We  do  not  go  into  great  detail  about  that  processor  other  than  to  state  that  the  pro- 
cessor is  a  full  microprocessor  of  the  Motorola  MC68000  class. 

The  contour  surface  display  generator  is  connected  to  the  Silicon  Graphics,  Inc.  IRIS  graph- 
ics system  by  means  of  the  IEEE  standard  Multibus  Backplane  Bus  [4  .  This  Multibus  connection 
provides  all  inputs  to  the  contour  surface  display  generator.  The  Multibus  interfaces  to  basically 
two  different  classifications  of  bus  modules:  (1)  Masters  -  those  modules  which  generate  com- 
mands, and  (2)  Slaves  -  those  which  respond  to  commands.  The  parent  processor  (MC68000)  is 
the  Master  module  for  the  graphics  system.  The  contour  surface  display  generator  is  a  slave 
module  in  that  system 

The  output  of  the  contour  surface  display  generator  is  to  the  Private  Bus  of  the  IRIS  system 
(Figures  3  and  6).  The  Private  Bus  is  a  unidirectional,  16  bit  bus  dedicated  to  the  provision  of 
coordinate  and  drawing  instructions  to  the  high  speed  Geometry  Engines.  Coordination  of  the 
transfer  of  data  between  the  algorithm  component  processors  and  the  Geometry  Engines  is  done 
via  a  two  line  handshake  protocol. 

When  the  contour  surface  display  generator  is  added  to  the  system,  a  physical  connection  to 
the  Geometry  Engine  pipeline  must  be  shared  by  both  itself  and  the  system  processor  (the  J3  con- 
nection of  the  Geometry  Engine  board).  To  enable  the  user  to  alternatively  route  processor  and 
generator  data  to  the  Geometry  Engines,  a  hardware  switch  is  added  to  the  system.  This 
hardware  provides  the  system  with  a  way  to  multiplex  the  direct  path  of  the  Private  Bus  A 
software  switch  then  provides  the  control  of  the  Private  Bus'  origin  and  configuration.  When 
activated,  this  switch  establishes  a  path  from  the  contour  surface  display  generator.  If  it  is  not 
activated,  the  IRIS  system  remains  in  its  original  configuration. 

4.    Hardware  Complexity  Estimate 

The  above  is  a  quick  overview  of  the  architecture  of  the  contour  surface  display  generator 
One  of  the  key  components  in  this  system  is  obviously  the  algorithm  component  processor     In    8  . 
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it  is  determined  that  50  algorithm  component  processors  are  all  that  are  needed  in  the  system  to 
generate  and  deliver  the  average  sized  picture  for  a  30  x  30  x  30  grid.  In  order  to  determine  the 
feasibility  of  the  complete  system,  we  need  a  circuit  complexity  estimate  for  the  size  of  the  algo- 
rithm component  processor.  In  |8],  we  find  a  summary  of  the  number  of  transistor  equivalent 
devices  necessary.  We  note  only  that  the  total  number  of  devices  required  for  one  algorithm  com- 
ponent processor  is  about  660K  devices.  This  number  is  well  below  the  two  million  devices  per 
chip  level  that  is  currently  being  produced  in  research  laboratories  [5]  For  this  level  of  chip  com- 
plexity, the  array  of  algorithm  component  processors  can  be  built  in  less  than  25  VLSI  chips.  At 
the  ten  million  devices  per  chip  level  promised  in  |7  ,  this  is  less  than  5  VLSI  chips.  The  design  of 
this  system  is  therefore    within  the  grasp  of  current  technology. 

5.    Conclusions 

This  study  is  intended  to  give  a  clearer  system  description  of  the  elements  comprising  the 
contour  surface  display  generator.  Some  of  the  deficiencies  of  earlier  research  were  remedied  by 
defining  the  control  lines  of  the  system.  The  technological  feasibility  of  the  system's  implementa- 
tion is  established  in  two  ways  The  first  is  that  a  realistic  number  of  algorithm  component  pro- 
cessors is  established  (50).  The  second  is  that  the  circuit  complexity  of  the  algorithm  component 
processor  chip  is  shown  to  be  within  the  capabilities  of  current  VLSI  technology. 

We  can  be  assured  that  once  we  produce  such  a  system  that  the  applications  user  will 
return  to  us  with  further  hardware  demands  for  either  other  algorithms,  or  additional  real-time 
graphics  display  generation  capabilities.  In  order  to  respond  to  these  desires  for  special  hardware 
for  select  applications  graphics  algorithms,  we  need  to  either  justify  the  special  hardware  effort  on 
the  basis  of  widespread  demand,  or  make  the  production  of  that  special  hardware  inexpensive 
We  cannot  count  on  the  widespread  demand  for  any  algorithm  for  which  we  desire  real-time  per- 
formance. The  only  solution  then  is  to  make  the  production  of  that  special  hardware  inexpensive. 
The  first  step  in  that  process  is  to  put  together  a  methodology  based  upon  experience  with  design- 
ing such  special  purpose  display  generators.  Once  that  methodology  is  sufficiently  developed,  we 
can  then  set  standards  for  the  production  of  such  systems.    We  can  see  an  analogy  in  the  world  of 


VLSI  design.  The  design  and  production  of  special  VLSI  chips  came  within  the  possibilities  of  the 
university  community  after  standard  interfaces  were  defined  for  chip  production.  Hence,  we  saw 
the  establishment  of  "silicon  foundries".  If  we  extend  this  idea  to  that  of  the  production  of  spe- 
cial hardware  for  select  graphics  algorithms  of  the  applications  user,  this  means  that  somewhere  in 
the  future  there  will  be  "real-time,  graphics  foundries".  It  is  towards  this  direction  that  we  can 
expect  future  developments  in  hardware  graphics  capabilities  to  proceed. 
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